其他
同样是高并发,QQ/微博/12306的架构难度一样吗?
UPDATE t_yue SET money=$new_money
WHERE uid=$uid AND money=$old_money;
UPDATE t_yue SET money=money-$diff WHERE uid=$uid;
UPDATE t_yue SET money=$new_money,ver=$ver_new
WHERE uid=$uid AND ver=$ver_old;
先分析三个业务场景。
个人:user(uid, user_info, …)
好友:user_friends(uid, friend_id, …)
加入的群:user_groups(uid, group_id, …)
群:group(gid, group_info, …)
群成员:group_members(gid, uid, …)
个人消息:msgs_user(msg_id, uid, …)
群消息:msgs_group(msg_id, gid, …)
select friend_id from user_friends where uid=$uid;
发消息,写操作
刷消息,读操作
查票,读操作
买票,写操作
stock(id, num) // 某一列车有多少张余票
UPDATE t_yue SET money=$new_money,ver=$ver_new
WHERE uid=$uid AND ver=$ver_old;
高并发的扣款场景,可以使用CAS乐观锁,采用select&set方式进行扣款,既能够保证吞吐量,又能够保证一致性。
《并发扣款一致性优化,CAS下ABA问题》
《并发扣款一致性,幂等性问题》
《读扩散?写扩散?》
任何脱离业务的架构设计,都是耍流氓。